Retry Policies
Retry policies improve workflow reliability by automatically repeating failed operations. Instead of immediately failing a workflow when a temporary error occurs, BindAI can retry the operation according to a configurable policy. Retries are commonly used for transient failures such as network interruptions, temporary API outages, or rate limits.What is a Retry Policy?
A retry policy defines how BindAI should respond when an operation fails. Conceptually:Why Use Retries?
Many failures are temporary rather than permanent. Examples include:- network timeouts
- temporary service outages
- rate limiting
- database connection failures
- cloud service interruptions
Retry Lifecycle
A retry-enabled operation follows this pattern.Retry Policy Configuration
BindAI provides a retry policy object. Typical configuration includes:- maximum attempts
- delay between attempts
- exponential backoff
Maximum Attempts
The retry policy limits how many times an operation may execute.Retry Delay
Retries usually wait before executing again.Exponential Backoff
Instead of using the same delay every time, exponential backoff increases the waiting period after each failure. Example:Success During Retry
If a retry succeeds, workflow execution continues normally.Permanent Failures
Retries cannot fix permanent problems. Examples include:- invalid credentials
- incorrect configuration
- invalid input
- missing resources
Retry vs Loop
Retries and loops serve different purposes.
Retries recover from transient errors.
Loops intentionally repeat workflow execution.
Retry Use Cases
Retry policies are commonly applied to:- API requests
- database operations
- cloud services
- document indexing
- external integrations
- AI model providers
- network communication
Error Handling
When all retry attempts fail, workflows can:- terminate execution
- route to an error handler
- notify administrators
- create a human task
- schedule another execution
Best Practices
- Retry only transient failures.
- Limit the maximum number of attempts.
- Use exponential backoff for external services.
- Log retry attempts for troubleshooting.
- Avoid retrying invalid requests.
- Combine retries with timeout policies where appropriate.
